Work flow of branches

  • STEPS

    HotFix

    1. HotFix branch intract with master branch .

    2. Delete hot branch after merging

    Feature

    1. Feature branch intract with developer branch.

    2. Delete feature branch after merging

    Release

    1. don't publish directly from develop branch to master branch.

    2. Use release branch.

    3. Delete release branch after merging

    1 Master branches

    The master branch is the production-ready version of our codebase which is automatically deployed to our production environment


    2. Dev branch

    The dev branch is where all feature branches are merged after pull requests have been thoroughly checked, fixed, and all tests are performed. Once all builds pass, this branch is deployed to the staging environment

    3 Feature branches

    Feature branch should be deleted

    Features should never interact directly with main.

    4 Release branches

    Once it's time for a release, a release branch should be created from the dev branch for final audit eg: cleanup & remove comments, versioning etc. This branch is tagged, and then merged to both master & dev branches.

    Release branch should be deleted

    Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it's ready to ship, the release branch gets merged into main and tagged with a version number. In addition, it should be merged back into develop


    5 Hotfix branches

    Hotfix branch should be deleted


  • Typical developer process

    1. Developer has a task to do.

    2. Developer branches dev, let's call it feature/user-registration.

    3. Developer works on feature/user-registration

    • Developer writes their own unit tests for feature/user-registration.

    4. Developer gets updates from dev when needed (by merging dev in). eg. "git pull origin dev"

    5. Developer publishes feature/user-registration

    • 1. Developer does a final update from dev.
    • 2. Developer makes sure their unit tests and all regression tests pass locally.
    • 3. Developer pushes feature/user-registration
    • 4. Developer makes sure their unit tests and all regression tests pass on build server.

    6. Developer submits pull request to dev

    • Pull request unit, integration and regression tests are run on build server.

    7. Admin merges pull request into dev branch which is built and deployed to staging for QA & UAT.

    • 1. Build server deletes remote feature/user-registration.
    • 2. Developer deletes local feature/user-registration.